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SECTION  1.  GENERAL 


1 .1  Purpose  of  This  Functional  Description 

This  Functional  Description  of  an  Electronic  Data  Interchange  System  for 
Defense  Fuel  Supply  Center  achieves  the  following: 

a.  Identifies  prospective  Electronic  Data  Interchange  (EDI)  projects.  The 
following  areas  have  been  identified  by  Defense  Fuel  Supply  Center  (DFSC) 
as  candidate  EDI  projects: 

(1)  Into-Plane.  The  EDI  system  will  provide  an  electronic  interface  between 
the  DFSC  and  contractors  that  supply  fuel  for  Into-Plane  purchases. 
Paper  invoices  and  aviation  fuel  sales  slips  will  be  converted  to  the 
American  National  Standards  Institute  (ANSI)  Accredited  Standards 
Committee’s  (ASC)  X12  EDI  standard  for  business  transactions.  The 
data  exchanged  will  conform  to  the  Aviation  Fuel  Providers  and  Users 
(AVNET)  Implementation  Guide  for  EDI. 

(2)  Bulk  Petroleum  Shippers  {PIPENET). 

(3)  Posts,  Camps,  and  Stations  (PC&S). 

(4)  Petroleum  Quality  Information  System  (PQIS). 

(5)  Bulk  Petroleum. 

(6)  Electronic  Procurement. 

(7)  Electronic  Funds  Transfer  (EFT). 

(8)  Electronic  Posting. 

(9)  Bunkers. 

(10)  Electronic  Mailing  List  Applications  [e.g..  Standard  Form  (SF)  129]. 

(11)  Government  Bills  of  Lading  (GBLs). 

(12)  Electronic  Point-of -Sale. 

(13)  Natural  Gas  (GasflowiGrade). 

(14)  Electronic  Aircraft  Refueling  Identification  System  (EARIS). 

(15)  Aircraft  Identa-plate. 

(16)  Modernization  of  Defense  Logistics  Standard  Systems  {MODELS). 
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b.  Identifies  the  system  requirements  to  be  satisfied  that  will  serve  as  a  basis 
for  a  mutual  understanding  between  the  user  and  the  developer. 

c.  Provides  information  on  system  performance  requirements,  preliminary 
design  considerations,  and  user  impacts  including  fixed  and  continuing 
costs. 

d.  Is  the  basis  for  the  development  of  system  tests. 

1.2  Project  References 

Documents  supporting  this  project  include  the  following: 

a.  Defense  Energy  Program  Policy  Memorandum  (DEPPM)  No.  89-2,  Office  of 
the  Assistant  Secretary  of  Defense  (Production  and  Logistics)  [OASD(P&L)] 
(L/EP),  14  July  1989. 

b.  AT&T  3B2  EDI  Translator  Evaluation,  DLA  Systems  Automation  Center 
(DSAC)-F,  14  December  1990. 

c.  Program  Implementation  Plan  (PIP)  for  Electronic  Commerce,  DFSC-ZF, 
28  May  1991. 

d.  DrdSt  AVNET  Implementation  Guide  for  EDI,  dated  June  1992. 

e.  EC/EDI/PLUS  Project  Survey,  DFSC-Z,  14  June  1991. 

f.  Economic  Analysis  of  the  Program  Implementation  Plan  (PIP)  for  Electronic 
Commerce,  DFSC-RO,  13  August  1991. 

1.3  Terms  and  Abbreviations 

a.  ASCX12.  An  "Accredited  Standards  Committee”  operating  under 
procedures  of  the  American  National  Standards  Institute  (ANSI)  to  develop 
uniform  standards  for  inter-industry  electronic  interchange  of  business 
transactions. 

b.  AVNET.  A  joint  project  of  the  Air  Transport  Association  of  America, 
American  Petroleum  Institute,  and  International  Transport  Association. 
The  goal  of  AVNET  is  to  develop  EDI  transactions  to  be  used  by  airlines  and 
companies  providing  the  supply  or  distribution  of  aviation  fuel  and  related 
products  and  services. 

c.  EDI.  Electronic  data  interchange.  The  computer-to-computer  exchange  of 
information  in  a  standard  format. 

d.  Into -Plane.  A  term  used  to  identify  the  process  associated  with  the  pa5Tnent 
of  aviation  fuel  sales. 


2 


SECTION  2.  SYSTEM  SUMMARY 


2.1  Background 

The  Deputy  Secretary  of  Defense  directed  the  DoD  Components  to  make  the 
maximum  use  of  EDI  for  the  paperless  processing  of  all  business- related  transactions. 
In  response  to  this  directive,  the  OASD(P&L)  issued  DEPPM  No.  89-2  which  directed 
that  EDI  be  used  to  improve  coordination  between  the  private  sector  and  DoD  and  to 
reduce  costs  through  the  reduction  of  paper  and  improved  energy  management. 

The  DFSC  was  designated  as  the  focal  point  for  managing  wholesale  petroleum 
and  natural  gas  EDI  efforts  and  for  establishing  projects  to  achieve  the  goals  of 
DEPPM  No.  89-2. 

2.2  Objectives 

The  goal  of  the  Defense  Energy  EDI  program  is  to  convert  85  percent  of 
existing,  routine  paper  business  documents  to  the  EDI  format  by  the  end  of  FY94. 
The  DFSC  established  the  following  subgoals: 

a.  Eliminate  DFSC’s  manual  processing  of  over  300,000  Into-Plane-related 
documents  a  year  received  from  250  separate  private  sector  fixed  base 
operators 

b.  Eliminate  the  manual  processing  of  paper  transfer  documents  between 
pipeline  companies  and  DFSC’s  fuel  regions 

c.  Reduce  the  workload  in  fuel  accounting  and  control  by  electronically 
capturing  data  at  the  time  fuel  is  dispensed  and  by  moving  that  data  directly 
to  the  accounting  systems  without  using  manual  processing. 

The  objective  of  the  EDI  system  is  to  provide  for  computer  application  to 
computer  application  exchange  of  business  information  in  computer-processable 
ANSI,  ASC  X12  standard  format.  The  EDI  system  will  provide  the  standard 
interface  between  software  application  systems  —  both  internal  and  external  to 
DFSC’s  automated  information  system. 
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2.3  Existing  Methods  and  Procedures 

This  subsection  briefly  describes,  by  functional  area,  the  current  methods  and 
procedures  being  employed  to  process  documentation  and  to  satisfy  the  existing 
interface  between  computer  applications  currently  being  used.  The  system 
relationships  to  manual  workflows  are  also  discussed. 

a.  Into-Plane.  Currently,  there  is  no  automated  interface  between  aviation 

fuel  suppliers  and  DFSC.  The  workflow  is  as  follows: 

(1)  The  fuel  suppliers  manually  prepare  and  submit  paper  invoices  along 
with  their  supporting  Aviation  Fuels  Sales  Slips  (DD  Form  1898)  for 
payment  of  purchases  made  by  approved  Government  agencies. 

(2)  The  invoices  and  "sales  slips”  are  mailed  by  fuel  suppliers  to  DFSC. 

(3)  Data  entry  clerks  validate  critical  data  indicated  on  the  forms  and  then 
they  enter  the  data  into  the  Automated  Voucher  Examination  and  Dis¬ 
bursement  System  (AVEDS).  If  data  errors  identified  cannot  be  cor¬ 
rected  by  the  DFSC  clerks,  the  forms  are  mailed  back  to  the  fuel  supplier. 

Figure  2-1  depicts  this  entire  process. 


start  End 


(DDForm  1898) 


FIG.  2-1.  CURRENT  MANUAL  PAPER  FLOW  PROCESSING  OF  FUEL  DOCUMENTS 
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(4)  Manual  handling  and  processing  of  paper  documents  requires  several 
labor-intensive  and  costly  activities  for  DFSC.  These  activities  include 
docxunent  sorting,  distribution,  reconciling  and  auditing,  data  entry, 
error  resolution,  mailing,  and  document  storage  and  retrieval.  Also, 
costs  incurred  associated  with  the  completion  of  similar  operations  at  the 
suppliers’  sites  are  passed  on  to  DFSC. 

b.  PIPENET  (to  be  developed). 

2.4  Proposed  Methods  and  Procedures 

This  subsection  describes  the  proposed  workflow  methods  and  procedures  by 
functional  area.  The  workflow  is  as  follows: 

a.  Into-Plane 

(1)  Aviation  fuel  suppliers  will  transmit,  through  EDI,  invoice  data  and  the 
associated  Aviation  Fuels  Sales  Slips  (DD  Form  1898)  data  to  DFSC 
using  the  AVNET  conventions  for  the  use  of  ASC  X12  EDI  standards. 

(2)  The  ASC  X12-formatted  data  will  be  automatically  converted  into  a 
neutral  file  format  by  the  EDI  system  and  will  be  released  to  AVEDS  for 
uploading. 

(3)  The  AVEDS/EDI  subsystem  will  validate  the  data. 

(4)  Nonprocessable  invoice  records  will  be  released  to  the  EDI  system  for 
conversion  to  ASC  X12  standards  and  transmission  back  to  the  sender. 

(5)  Valid  invoice  records  will  be  identified  as  EDI  records  and  processed  by 
AVEDS.  Figure  2-2  depicts  the  Into-Plane  information  flow. 

b.  PIPENET  (to  be  developed). 
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FIG.  2-2.  PROPOSED  EDI  METHOD  FOR  PROCESSING  INTO-PLANE  TRANSACTIONS 


2.4.1  Summary  of  Improvements 

The  use  of  the  EDI  system  to  replace  the  manual  paper  document  flow  will 
result  in  direct  cost  savings.  These  costs  include  the  cost  of  document  distribution 
(making  copies  and  distributing  them  among  users);  mailing  (principally  the 
purchase  of  stamps  and  envelopes);  document  sorting,  reconciling,  and  auditing 
(comparing  the  document  to  other  documents);  data  entry;  error  resolution  (checking 
for  and  correcting  mistakes);  document  storage  and  retrieval;  and  telephone  usage. 
Other  benefits  will  result  from  improved  information  flow  and  greater  data  accuracy. 

2.4.2  Summary  of  Impacts 

2.4.2.1  User  Organizational  Impacts.  The  EDI  system  will  cause  a  redistrib¬ 
ution  of  resources  as  a  result  of  the  elimination  of  manual  processes  associated  with 
paper  documents.  This  redistribution  of  resources  will  occur  primarily  in  the  areas  of 
document  processing  and  data  entry. 

2.4.2.2  User  Operational  Impacts.  The  EDI  system  replaces  the  manual  proces¬ 
sing  of  input  and  output  paper  documents  associated  with  DFSC’s  standard  systems. 
The  input  and  output  processes  of  these  systems  will  be  impacted  the  most  by  EDI. 
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Other  user  operations  currently  associated  with  processing  the  data  in  their 
electronic  form  will  not  be  significantly  impacted. 

2.4.23  User  Development  Impacts.  The  EDI  system  only  provides  a  standard 
electronic  interface  between  application  systems.  As  a  result,  the  current  application 
functions  do  not  change  significantly.  During  development,  users  will  be  required  to 
define  input  and  output  data  requirements,  edit  criteria,  and  data  security  require¬ 
ments.  Users  will  also  be  required  to  support  parallel  operations  during  the  testing 
phase  of  the  system. 

2.5  Assumptions  and  Constraints 

The  focus  of  the  EDI  system  is  on  the  elimination  of  manual  processes 
associated  with  paper  input  and  output  documents.  Changes  to  the  applications 
systems  should  be  limited  to  input  and  output  processes.  Other  functions  associated 
with  the  application  should  not  change. 


7 


SECTION  3.  DETAIL  CHARACTERISTICS 


3.1  Specific  Performance  Requirements 

Inbound  EDI  batch  transmissions  are  received  daily  from  participating  contrac¬ 
tors.  Each  batch  is  validated,  translated  from  an  ASC  X12  format  to  a  file  format 
acceptable  to  the  application  systems,  and  uploaded  on  demand.  Acceptance  and 
rejection  data  are  created  for  outbound  translation.  Before  and  during  the  transla¬ 
tion  process,  critical  files  are  backed-up  for  recovery  and  audit  trails  are  created. 
Outbound  EDI  data  are  downloaded  from  the  application  systems  in  a  file  format 
acceptable  to  the  translator.  Outbound  data  are  translated  into  ASC  X12  format, 
prepared  for  transmission,  and  transmitted  to  the  participating  contractors. 

3. 1. 1  Accuracy  and  Validity 

The  EDI  system  will  validate  ASC  X12  transmission  header/trailer  formats, 
transmission  and  functional  group  counts,  ASC  X12  syntax  and  code  compliance  and 
create  an  interchange  and  functional  acknowledgment  transaction  set  to  indicate  the 
results  of  the  syntactical  analysis  of  the  electronic  transmission.  This  functional 
analysis  does  not  cover  the  semantic  meaning  and  accuracy  of  the  data  elements; 
that  is  a  function  of  the  application  program.  Tables  3-1  and  3-2  provide  the  data 
elements  that  must  be  present  and  valid  for  AVEDS  input  records  to  be  accepted. 

3.1.2  Timing 

The  timing  of  transactions  is  critical  to  the  smooth  flow  of  work  and  directly 
affects  the  EDI  network  transmission  cost  (off-peak  hours  are  less  costly). 

a.  The  system  will,  at  a  minimum,  complete  all  transaction  processing  and  all 
communications  within  24  hours. 

b.  The  system  will  respond  to  users  in  3  seconds  during  on-line  editing  and 
updating. 

c.  The  communication,  translation,  and  security  subsystems  are  subordinate  to 
the  system  control  subsystem. 

d.  Production  transactions  will  be  given  priority  over  test  transactions  during 
the  testing  period. 
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TABLE  3-1 


INVOICE  RECORD 


TABLE  3-2 

SUPPORTING  AVIATION  FUELS  SALES  SLIPS 
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3.1.3  Capacity  Limits 

The  implementation  strategy  calls  for  a  pilot  test  with  phased  implementation 
of  application  areas.  Initial  transaction  volumes  will  be  small  and  build  to  a  total  of 
220,000  per  year  over  a  5-year  period. 

3.2  Functional  Area  System  Functions 

a.  Into-Plane.  An  AVEDS  EDI  subsystem  will  integrate  EDI  data  files  (invoice 
and  delivery  tickets)  for  processing  by  AVEDS.  The  subsystem  will  initiate 
the  uploading  of  the  EDI  invoice  and  delivery  ticket  data  files  and  prepare 
the  data  for  batch  editing.  The  edit  criteria  employed  by  the  EDI  system  will 
be  identical  to  the  criteria  used  by  AVEDS  for  transactions  entered  during 
data  entry.  A  daily  AVEDS/EDI  transaction  listing  (report)  will  be 
produced.  This  listing,  containing  both  valid  and  invalid  transactions  will 
be  used  to  monitor  processing  and  will  become  part  of  the  audit  trail. 
Rejected  EDI  transactions  will  be  available  on-line  for  subsequent  corrective 
action  and  eventual  release  for  continued  processing.  Validated  EDI 
transactions  will  be  processed  in  the  same  way  as  transactions  that  entered 
AVEDS  during  the  data  entry  process. 

b.  PIPENET  (to  be  developed). 

3.3  Inputs,  Outputs,  and  Data  Base  Characteristics 

The  EDI  system  replaces  data  entry  and  paper  output  with  electronic 
equivalents  for  selected  (standard  system)  high- volume  transactions. 

Into-Plane. 

(1)  Inputs.  Tables  3-3  and  3-4  contain  the  data  element  names,  record 
identifiers,  and  record  positions  for  the  AVEDS/EDI  input  files  for 
invoice  and  delivery  ticket  records  (also  called  aviation  fuels  sales  slips). 
Refer  to  the  AVEDS  Data  Element  Dictionary  for  detailed  data 
characteristics. 

(2)  Outputs. 

(a)  Daily  AVEDSIEDI  Transaction  Listing.  This  report  listing  will 
provide  a  record  of  valid  and  invalid  transactions  and  will  be  used  to 
monitor  daily  performance.  The  report  also  provides  an  input  audit 
trail. 

(b)  Rejected  EDI  Transactions  for  Correction.  This  report  will  be  avail¬ 
able  on-line  to  facilitate  correction  of  invalid  records. 
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TABLE  3-3 

INVOICE  FILE  RECORD  LAYOUT 


Data  element  name  fields 
for  AVEDS  input  files 

Record  identifier 
(positions  17-18) 

Record 

positions 

invoice.no 

10 

19-24 

DATE.RECEIVED 

10 

25-30 

CONTR.AGRMT.NO.ABRV 

10 

31-43 

control.no 

10 

44-54 

INVOICE.DATE 

10 

55-60 

BILL.MOD.EFF.PERD.START 

10 

61-66 

BILL.MOD.EFF.PERO.END 

10 

67-72 

dlvy.ord.no 

11 

19-22 

ADJUSTMENT.INVOICE 

12 

17-18 

DISCOUNT.TYPE 

15 

19-20 

DISCOUNT.RATE 

15 

21-26 

DISCOUNT.DAYS 

15 

27-29 

DISCOUNT.CENTS 

15 

30-34 

DISCOUNT.UNITS 

15 

35-36 

CLIN 

20 

19-24 

DOD.FM.1898.SERNO 

20 

25-30 

UNIT.OF.MEAS 

20 

31-32 

QT.BILLED 

20 

33-42 

UP.BILLED 

20 

43-50 

CLIN.INVOICE.AMOUNT 

20 

51-61 

DOD.FM.1898.SERNO.DATE 

20 

62-67 

DEFUEL.CLIN 

20 

68-73 

RESERVICE.CLIN 

20 

68-73 

TOTAL.AMOUNT.BILLED 

30 

19-29 

TAXES 

30 

30-37 

Note:  Several  input  records  may  occur  within  a  single  transmission.  Record 
identifiers  (e.g.,  types  10,  15,  20,  etc.)  appear  grouped  together  and  in  sequential  order. 
The  occurrences  of  new  lower  numerical  record  identifiers  signal  the  beginning  of  a  new 
transaction  (e.g.,  a  type  10  following  a  type  30). 
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TABLE  3-4 


DD  FORM  1898  FILE  RECORD  LAYOUT 


Data  element  name  fields 
for  AVEDS  input  files 

Record  identifier 
(positions  17-18) 

Record 

positions 

CONTR.AGRMT.NO.ABRV 

40 

19-31 

OOD.FM.1898.SERNO 

40 

32-38 

DD  FORM1898.JULN.DT 

40 

39-44 

AMDS 

50 

19-21 

DODAAC 

50 

22-27 

TAIL.SERNO 

50 

28-31 

FUND.CD 

50 

32-33 

MAJ.FRC.PGM 

51 

22 

SIG.CD 

52 

22 

SUPAAC 

53 

22 

CUST.ID 

54 

24 

AVFUEL.CLIN 

60 

19-24 

AVFUEL.QTY 

60 

25-33 

AVFUEL.UM 

60 

34-35 

DEFUEL.CLIN 

70 

19-24 

DEFUELQTY 

70 

25-33 

DEFUELUM 

70 

34-35 

DEFUEL.PROD.CLIN 

70 

36-41 

RESERVICE.CLIN 

80 

19-24 

RESERVICE.QTY 

80 

25-33 

AVOILCLIN 

90 

19-24 

AVOIL.QTY 

90 

25-33 

AVOiL.UM 

90 

34-35 

Note:  Several  input  records  may  occur  within  a  single  transmission.  Record 
identifiers  (e.g.,  types  40,  70,  90,  etc.)  appear  grouped  together  and  in  sequential 
order.  The  occurrences  of  new  lower  numerical  record  identifiers  signal  the 
beginning  of  a  new  transaction  (e.g.,  a  type  40  following  a  type  90). 


3.4  Failure  Contingencies 

User  notification. 

Users  will  be  notified  of  expected  system  operational  delays  lasting  over 
24  hours  and  asked  to  stop  input.  If  the  EDI  system  is  expected  to  be  "down”  for  more 
than  48  hours,  users  will  be  given  the  options  of  stopping  input  or  completing  paper 
input  documents  for  subsequent  (batch)  data  entry  at  DFSC.  If  the  standard  system 
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which  interfaces  with  the  EDI  system  is  expected  to  be  down  more  than  72  hours, 
users  will  be  given  instructions  based  upon  the  contingencies  established  for  that 
standard  system. 
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SECTION  4.  DESIGN  CONSIDERATIONS 


4.1  System  Description 

The  proposed  EDI  system  shown  in  Figure  4-1  is  composed  of  both  software  and 
hardware.  The  system  has  the  ability  to  exchange  data  between  computer  applica¬ 
tions  electronically  using  ASC  X12  standard  transactions.  This  is  accomplished  by 
interfacing  the  EDI  system  with  the  current  application  systems  that  are  external 
and  internal  to  DFSC. 


Private  sector 


FIG.  4-1.  PROPOSED  EDI  SYSTEM 
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4.2  System  Functions 

Figure  4-2  shows  the  relationships  between  system  functions.  The  functions  are 
as  follows: 

a.  System  control  provides  the  primary  means  for  controlling  the  interfaces 
with  external  applications. 

b.  Communication  ensures  proper  data  transmission  and  network  access. 

c.  Translation  converts  application  data  files  to  and  from  ASC  X12  standard 
transactions. 

d.  Security  logically  secures  the  EDI  transactions  to  prevent  or  detect  tam¬ 
pering  or  unauthorized  disclosure. 


FIG.  4-2.  EDI  SYSTEM  FUNCTIONS 


4.3  Flexibility 

To  facilitate  change  and  ease  of  maintenance,  the  EDI  system  will  be  directory 
and  table  driven.  Each  subsystem  will  be  modular  and  capable  of  independent  opera¬ 
tion.  The  system  control  subsystem  will  isolate  the  application  systems  from  the 
transaction  subsystem  to  protect  them  from  expected  changes  in  the  ASC  X12 
standards.  The  communication  subsystem  will  isolate  the  application  systems  from 
changes  in  the  communication  environment. 
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4.4  System  Data 

Inputs  are  received  from  external  EDI  systems  in  what  is  known  as  an 
'^electronic  envelope.”  Each  input  record  is  arranged  in  an  electronic  envelope  as 
indicated  in  the  example  below.  The  electronic  envelope  contains  both  control  and 
application  data.  Application  and  control  data  are  arranged  in  transaction  sets 
which  conform  to  ASC  X12  standards.  The  list  below  illustrates  the  nested  input 
data. 


Communication  Transport  Protocol 
Interchange  Control  Header 

Interchange  Acknowledgment 
Functional  Group  Header 
Transaction  Set(s) 
Functional  Group  Header 
Interchange  Control  Trailer 
Communication  Transport  Protocol 


V  Electronic  Envelope 


J 


Inputs  from,  and  outputs  to,  DFSC’s  internal  systems  will  be  simple  file  structures 
containing  fixed-length  records. 
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SECTION  5.  ENVIRONMENT 


This  section  describes  the  current  ADP  environment  and  forecasts  the  environ¬ 
ment  needed  to  satisfy  the  requirements  delineated  in  Sections  2  and  3. 

5.1  Equipment  Environment 

The  EDI  system  hardware  shown  in  Figure  5-1  consists  of  the  following  compo¬ 
nents: 

a.  A  central  processing  unit  (CPU)  with  a  console  and  printer  and  16  mega¬ 
bytes  (Mb)  of  main  memory 

b.  One  300  Mb  fixed-disk  drive,  one  720  kilobytes  (Kb)  flexible-disk  drive,  one 
9  track  tape  drive,  and  one  1  inch  cartridge  tape  drive 

c.  One  high-speed  line  printer 

d.  Four  personal  workstations  with  display  terminals,  a  printer,  and  a  flexible- 
disk  storage  capability. 

5.2  5upport  5oftware  Environment 

The  EDI  system  will  use  the  Defense  Logistics  Agency’s  (DLA’s)  UNIX 
System  V  standard  support  software  configuration  for  EDI.  This  includes  a  rela¬ 
tional  data  base,  ASCENT  gateway  with  supporting  telecommunication  software, 
ADA  and  C  compilers,  and  supporting  software  utilities. 


19 


FIG.  5-1.  PROPOSED  EDI  SYSTEM  HARDWARE 

5.3  Communications  Requirements 
S.3.1  Graphic  Overview 

The  EDI  system  will  electronically  link  computers  from  different  contractors 
(trading  partners)  and  other  Government  agencies.  This  linkage  will  be  directly 
between  individual  activities  or  through  VANs  and/or  direct  dial  (either  public  or 
Government).  Refer  to  Figure  5-2. 
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FIG.  5-2.  COMMUNICATIONS  REQUIREMENTS 


5.3.2  Hardware 

The  following  are  the  communications  hardware  components  known  to  be 
required  to  support  the  proposed  system: 

a.  Four,  8-port  I/O  controllers  for  connecting  synchronous  peripheral  devices 

b.  IBM  3270/3274  emulation  port  to  access  an  IBM  host  (mainframe)  and 
emulate  IBM  terminals  and  devices 

c.  Ethernet  controller 
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d.  X.25  I/O  controller 

e.  Six  modems. 

5.3.3  Software 

The  following  are  the  communications  software  applications  known  to  be 
required  to  support  the  proposed  system: 

a.  Defense  Data  Network  protocol,  file  transfer,  virtual  terminal.  Simple  Mail 
Transport,  and  Berkeley  ”R”  Series  commands 

b.  UNIX-to-UNIX  communication 

c.  Transmission  Control  Protocol/Internet  Protocol. 

d.  Carrier  Sense,  Multiple  Access  with  Collision  Detection  IEEE  802.3  stand¬ 
ard  for  an  Ethernet  LAN. 

e.  PC-to-UNIX  (emulation)  program  allows  the  workstation  to  act  as  a  termi¬ 
nal  connected  to  the  host 

f.  PC-interface  software  for  MS-DOS  interaction  with  UNIX  host. 

5.4  Interfaces 

The  EDI  system  will  interface  with  DFSC’s  standard  application  systems  to 
provide  input  data  and  receive  output  data  for  translation  into  ASC  X12  standard 
formats.  The  interface  will  be  accomplished  by  file  transfers  between  systems.  The 
format  of  the  files  will  be  a  fixed-length  record  and  neutral  to  both  systems. 

The  VAN  interface  will  be  accomplished  using  UNIX-to-UNIX  communication 
or  Transmission  Control  Protocol/Internet  Protocol  software. 

The  EDI  system  users  will  use  the  PC-to-UNIX  (emulation)  program,  which 
allows  the  workstations  to  act  as  a  host  terminal,  and  the  PC-interface  software  for 
MS-DOS  interaction  with  the  UNIX  host. 

5.5  Summary  of  Impacts 

5.5. 1  ADP  Organizational  Impacts 

The  introduction  of  the  EDI  system  into  the  existing  ADP  operational  environ¬ 
ment  will  require  additional  manpower  for  system  operation  and  software  support. 
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An  EDI  project  differs  from  traditional  internal  automation  projects  in  that 
planning,  development,  and  implementation  tasks  must  be  performed  by  organi¬ 
zations  outside  of  DoD’s  authority  and  control,  which  adds  an  additional  level  of 
complexity  to  the  project  manager’s  tasks.  To  offset  this  control  problem,  an  EDI 
manager  must  be  appointed  at  a  grade  level  that  will  facilitate  coordination  at  the 
corporate  level.  Implementing  the  EDI  system  will  involve  many  people  in  a  variety 
of  roles.  It  will  require  a  great  deal  of  coordination  between  the  functional  managers 
and  the  automation  managers.  At  a  minimum,  manpower  should  be  provided  as 
follows: 

a.  Project  manager 

b.  Functional  coordinator  (for  each  business  area  impacted) 

c.  Technical  coordinator 

d.  EDI  coordinator. 

5.5.2  ADP  Operational  Impacts 

The  implementation  strategy  calls  for  a  pilot  test  with  phased  implementation 
of  other  application  areas.  There  must  be  an  initial  allocation  of  manpower  for  the 
pilot  test  —  with  the  allocation  of  additional  manpower  being  timed  with  the  imple¬ 
mentation  of  other  applications. 

5.5.3  ADP  Development  Impacts 

The  DLA’s  standard  application  interface  information  exchange  (INX)  along 
with  commercial  software  will  be  used  to  reduce  the  EDI  system  development 
requirements.  Manpower  for  the  EDI  system  will  be  required  for  integration  and 
implementation  of  the  system  within  DFSC’s  existing  ADP  environment.  Applica¬ 
tion  development  manpower  will  be  required  to  change  existing  programs  to  accept 
files  from,  and  output  files  to,  the  EDI  system.  There  must  be  an  initial  allocation  of 
resources  for  the  pilot  test.  Additional  manpower  must  be  allocated  and  timed  with 
the  implementation  of  the  applications. 

5.6  Assumptions  and  Constraints 

The  hardware  and  software  environments  will  conform  to  the  DLA’s  standard 
application  interface  (information  exchange). 
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SECTION  6.  SECURITY 


6.1  Background  Information 

Classified  data  will  not  be  processed  on  the  system;  however,  the  elimination  of 
paper  document  processing  will  require  changes  to  existing  security  processes  and 
procedures.  Sufficient  controls  will  be  provided  by  the  EDI  system  to  ensure  confiden¬ 
tiality,  integrity,  and  availability. 

6.2  Control  Points,  Vulnerabilities,  and  Safeguards 

The  EDI  system  provides  controlled  access  to  data,  a  read-only  capability  for 
extracted  data,  control  counts  on  file  transfers,  generation  of  an  audit  trail, 
archiving,  and  restart  facilities.  The  controls  provided  by  the  EDI  system  will  match 
the  existing  controls  in  the  application  systems  to  ensure  a  consistent  security  policy. 

6.3  System  Monitoring  and  Auditing 

Software  compliant  with  the  ASC  X12  standards  has  procedures  designed  to 
ensure  the  integrity  of  data.  When  an  EDI  transmission  is  received,  the  software 
verifies  that  all  required  headers  and  trailers  (interchange  level,  functional  group 
level,  and  transaction  set  level)  are  present,  that  they  have  identical  control 
numbers,  and  that  trailer  counts  are  equal  to  those  counted  by  the  software.  The 
results  of  this  validation  process  are  documented  in  system  generated  reports  and  in 
the  functional  acknowledgment  sent  electronically  to  the  originator  of  the  EDI 
transmission. 
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SECTION  7.  SYSTEM  DEVELOPMENT  PLAN 

To  expedite  implementation  of  the  pilot  system,  developers  of  the  EDI  system 
will  use  the  DLA-supported  INX  application  interface  software,  commercially 
available  American  Business  Computer  ExCel  EDI  translation  software  (recom¬ 
mended  by  DLA),  and  the  AT&T  3B2  Computer  (currently  on  Government  contract). 
Commercial  VAN  services  will  be  obtained  through  an  existing  DFSC  contract. 
(DFSC  will  migrate  to  the  DoD  standard  EDI  system  when  it  becomes  available.) 

Into-Plane  (AVEDS)  will  be  the  first  application  system  to  receive  EDI  data. 

Once  the  pilot  system  is  operational,  phased  testing  will  begin  with  Mobil 
International  Aviation  and  Marine  Sales  to  verify  data  requirements  and  system 
operation. 

Concurrent  with  this  testing,  an  AVEDS/EDI  subsystem  will  be  developed  to 
provide  an  interface  between  AVEDS  and  the  EDI  system. 

After  successful  production  testing  of  new  procedures  and  the  AVEDS/EDI 
subsystems  with  Mobil,  other  Into-Plane  contractors  will  be  migrated  to  the  EDI 
system.  During  this  period,  the  decision  to  begin  development  of  other  applications 
will  be  made. 
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SECTION  8.  COST  FACTORS 


The  proposed  system’s  costs  are  documented  in  DFSC-RO  Inter-Office 
Memorandum,  Subject:  Economic  Analysis  of  the  Program  Implementation  Plan 
(PIP)  for  Electronic  Commerce,  dated  13  August  1991  and  a  DFSC-Z  letter, 
Subject:  EC/EDIIPLUS  Project  Survey,  dated  14  June  1991.  The  estimated  costs  are 
summarized  below. 


Nonrecurring  costs  ($) 


Hardware 

197,000 

Software 

35,000 

Site 

1,000 

Analysis 

50,000 

Training 

2,000 

Total 

$  285,000 

Recurring  costs  (over  8  years) 

Personnel 

2,788,000 

Telecommunications 

65,000 

System  maintenance/operation 

134,000 

Training 

35,000 

Supplies 

7,000 

Total 

$  3,029,000 
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